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COPYRIGHT NOTICE 
A portion of the disclosure of this patent document contains material 
which is subject to copyright protection. The copyright owner has no 
objection to the facsimile reproduction by anyone of the patent document 
15 or the patent disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

This application claims priority from U.S. provisional patent 
20 applications "OPEN MARKET PLATFORM SYSTEM FOR CONDUCTING 
WEB BASED BUSINESS", Application No. 60/183,067, filed February 
1 6, 2000, incorporated herein by reference and "OPEN MARKET 
PLATFORM SYSTEM FOR CONDUCTING WEB BASED BUSINESS", 
Application No. 60/258,804 , filed December 29, 2000, incorporated 
25 herein by reference. 

Cross-Reference Cases: 

The following applications are cross-referenced and incorporated 
herein by reference: 
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U.S. Application entitled "OPEN MARKET COLLABORATION 
SYSTEM FOR ENTERPRISE WIDE ELECTRONIC COMMERCE," by 
Rocky Stewart, Timo Metsaportti, and Pal Takacsi-Nagy, filed February 
16, 2001. 

U.S. Application entitled "MESSAGE ROUTING SYSTEM FOR 
ENTERPRISE WIDE ELECTRONIC COLLABORATION," by Rocky 
Stewart, Pal Takacsi-Nagy, Timo Metsaportti, and Michael Hyndman, filed 
February 16, 2001. 

U.S. Application entitled "CONVERSATION MANAGEMENT 
SYSTEM FOR ENTERPRISE WIDE ELECTRONIC COLLABORATION," 
by Rocky Stewart, Pal Takacsi-Nagy, Timo Metsaportti, Sanjay Dalai and 
Pascal Hoebanx, filed February 16, 2001 . 

U.S. Application entitled "WORKFLOW INTEGRATION SYSTEM 
FOR ENTERPRISE WIDE ELECTRONIC COLLABORATION," by Rocky 
Stewart, Pal Takacsi-Nagy, Timo Metsaportti and Adrian Price, filed 
February 16, 2001. 

Field of the Invention: 

The present invention relates generally to the transaction of 
business-to-business commerce using the Web. 

Background of the Invention: 

To prosper in the Internet economy, a company must be able to 
streamline its business process, eliminate unnecessary cost, and react 
quickly to competitive pressures. To support this mandate, information 
technology (IT) organizations must have the ability to rapidly consolidate 
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systems from newly created or incorporated divisions and, in many cases, 
to exchange mission-critical information with outsourced partners as a 
virtual enterprise. New Internet applications must be linked with each 
enterprise's core technologies to deliver accurate information, solid 

5 operational performance, and a satisfactory customer purchase 

experience. And, whether companies do business on the Web or not, 
customers expect all businesses to run on Internet time — a rapid pace 
that calls for seamless, high-performance business operations that can be 
accomplished only when applications are integrated with each other to 

10 create the zero latency enterprise. 

The first business issue is the integration of critical business 
information and logic that reside in enterprise production and legacy 
systems. Multiple IT systems that are implemented as silos or standalone 
systems, each addressing particular business issues, should be integrated 

15 across the enterprise. 

Traditionally, islands of individual applications that need to share 
data have been integrated in an ad hoc manner, using homegrown 
integration and, more recently, Enterprise Application Integration (EAI) 
toolsets. These hard-coded and point-to-point solutions attempted to 

20 address the problem but created an IT nightmare of innumerable 

spaghetti-like connections between applications. EAI solutions that cobble 
together a combination of point-to-point interfaces, procedure calls, file 
transfers, and "e-mail-like" messaging to deliver enterprise-wide data 
transformation and routing are notoriously high risk. 

25 Further, multiple point-to-point and ad hoc solutions are inherently 

difficult to deploy and maintain because they lack a centralized 
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management and support for real-time change management. These 
features are desirable to the management of business processes and the 
goal of addressing the e-commerce integration environment. 

The second business issue is the need to incorporate Web-based, 

5 e-commerce applications. The goal of getting on the Web, however, was 
not a simple one; only new businesses starting from scratch had the luxury 
of building from the ground up. With substantial IT infrastructures and 
investments in place, most businesses were faced with having to leverage 
current information systems and merge them into the e-commerce age. 

10 Businesses that are not able to integrate customer-facing Web 

applications with enterprise systems find that they simply cannot support 
today's competitive market and customer demands. This is because data 
is locked away in disparate systems that do not speak the same language, 
much less speak to each other. 

15 The third business issue is taking full advantage of integrated e- 

commerce, including the integration of business processes with trading 
partners. E-Commerce enables companies to enjoy significant savings 
and increase revenue opportunities by (1) improving service to customers, 
(2) engaging in just-in-time production, (3) finding more competitive 

20 providers of operational goods and production materials, and (4) being 

able to create new markets quickly. These two objectives — reducing cost 
and increasing revenue — have always been driving business forces. 
However, to date, there has been no solution that has provided the key 
enablers for e-business. Electronic data interchange (EDI) emerged in the 

25 1 990s as a standard for exchanging data between companies. EDI is a 
highly structured, expensive, and time-consuming technology. Packaged 
solutions have also emerged that claim to solve business-to-business 
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(B2B) dilemmas; however they also require heavy investment in 
proprietary application technology across all business partners, entail 
significant configuration expertise, and deliver a hard-coded, pre- 
packaged process that all parties must adopt. Packaged solutions and 

5 EDI deliver very little competitive advantage, are not customizable for 

differing business processes, and are expensive, time-consuming options. 

Most people are familiar with the traditional EDI batch mode type of 
B2B, and with the more recent electronic store fronts of dot-coms, 
otherwise referred to as basic commerce. While both EDI and basic 

10 commerce provide companies with business advantages that were not 
previously available — the high costs and technical constraints of 
implementing EDI and the minimal transaction functionality of basic 
commerce have limited their adoption as long-term e-business strategies. 
Community commerce, the third type of B2B e-commerce, features the 

15 same characteristics of basic commerce — the simple matching of buyers 
and sellers online — with perhaps some added functionality, such as 
auction and search, and the sharing of common information with vertical or 
community groups. However, these three types of commerce share one 
common limitation — they do not involve real-time, dynamic conversations 

20 between businesses. The sharing of information is in the form of simple 
point-to-point messages that are not really conversations. While these 
types of commerce may be sufficient to do things like sharing simple 
inventory information with suppliers, or posting product catalogs for 
buyers, these types of commerce have, to date, done little more than 

25 simply take information and automate its distribution to participants. 
Existing B2B models fall short in meeting modern day 
requirements. From EDI and outsourced procurement to supply chain 
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management systems and first-generation online exchanges, companies 
are feverishly searching out technology that will enable them to quickly, 
efficiently, and reliably conduct business with trading partners over the 
Internet. Unfortunately, companies are discovering that most of these 
5 traditional B2B technologies meet only a fraction of their e-business IT 
requirements. A more comprehensive, powerful and flexible solution is 
required to successfully meet the challenges of collaborative B2B 
commerce today. 

While EDI offers an advantage over paper-based business 

10 transactions, it has traditionally been restricted to large companies with 
substantial IT budgets and technical resources. EDI typically requires as 
much as 9-12 months to implement and can be quite costly. Finally, EDI is 
not real-time or process-driven. Data is batch transmitted, and 
transactions can be sent out of sequence without system oversight. In 

15 some cases, data may not be received at all — creating consternation and 
confusion on all sides. 

Unlike EDI, new B2B solutions are designed to leverage the Internet 
and technologies such as Java, in order to lower the barriers to entry for 
trading partners of any size, reduce deployment cycles and cost, and 

20 power managed, real-time communication between partners. Recognizing 
that EDI will continue to be used by many of the world's largest companies 
because of familiarity and confidence in legacy systems, new 
Internet-based e-business platforms must also co-exist comfortably with 
EDI legacy systems. Nonetheless, as the real and opportunity costs of 

25 using EDI grow, companies are investing IT resources in Internet-based 
systems that make more financial and strategic sense. 
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Another commonly found form of B2B interaction is the use of 
outsourced e-procurement applications. Web-based purchasing of 
maintenance, repair, and operation (MRO) supplies— the goods required 
to run a company but not the materials used in the direct manufacture of a 

5 product or the provision of a service — is becoming more and more 
common every day. To deliver process efficiencies and cost savings, 
many companies have outsourced their MRO provisioning to third parties 
because these goods are non-strategic, low-cost items that can be 
intermittently purchased in bulk from a pre-established set of suppliers. 

10 However, from a technology perspective, outsourced 

e-procurement is much like EDI in that it increases efficiency over 
paper-based processes but is also monolithic, inflexible, and requires all 
participants to adopt a single proprietary application. This does not enable 
customers to create competitive advantage by streamlining their 

15 mainstream purchasing process or doing business any differently than 
direct competitors. These serious limitations, combined with the fact that 
MRO vendors typically own all the data associated with using their 
exchange, mean that most companies are reluctant to consider 
e-procurement vendors for their core or strategic enterprise functions. In 

20 fact, some participants in MRO exchanges may consider e-procurement 
vendors as potential downstream competition and are careful to limit the 
scope of business conducted on these sites. 

Given these factors, while many companies may continue using 
MRO procurement for a portion of their e-business portfolio, they must still 

25 acquire strategic technology that will encompass MRO exchanges but 
support larger and more strategic e-business objectives. 
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Some organizations have implemented B2B solutions as a 
first-generation online exchanges for e-markets and supply chain 
management. An e-market maker can be defined as an organization that 
develops a B2B, Internet-based, e-marketplace of buyers and sellers 

5 within a particular industry, geographic region or affinity group. The list of 
e-market makers is growing larger every day. 

Although it is indisputable that e-marketplaces in general will power 
much of e-business tomorrow, supporting a broad variety of collaboration, 
purchasing sales and trading activities, the majority of them are not 

10 delivering on the B2B promise today. A recent research study found that 
of 600 surveyed exchanges, only 10 provided application integration. A 
primary goal of B2B and online marketplaces is to reduce human 
intervention. This goal cannot be achieved unless systems are integrated 
from end-to-end. 

15 E-Markets without back-end integration to a company's enterprise 

systems significantly reduces the return on investment for e-market makers 
and participants, and limits that company's opportunities to satisfy 
customers in new and unique ways. Supply chain transparency, which 
occurs when e-market makers have increased visibility into a supplier's 

20 product availability and delivery information, enables B2C companies to 
better meet customer demands in real-time and represents a significant 
source of competitive advantage. The differentiating factor between two 
supply chains often boils down to which one is better at managing the 
information float — the time between when data is captured in one place 

25 and when it becomes available and actionable elsewhere. 

As e-markets continue to proliferate — interconnecting with each 
other and growing into tomorrow's interconnected e-business "power grid" 
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— they promise to super-charge the B2B network effect. E-businesses 
need to respond quickly to market demand, and as such look to build not 
just their own supply chains but also those of their customers and suppliers. 
These benefits will flow through entire industry segments as information 
5 improves, order processing becomes easier, and all parties can begin to 
rely on getting what they need to meet customer demands in a timely 
fashion. 

Summary of the invention: 

10 The need to move both operational and customer information at 

high speed from one end of a distributed enterprise to the other, as well as 
beyond its firewalls, creates an e-commerce environment that can be 
adequately addressed only with an end-to-end integration architecture. 
E-Business is about competition, and competition is about service 

15 speed and quality. Company size and scope are no longer the determining 
factors for marketplace success, because even very small companies can 
generate a significant Internet presence. Capturing new business 
opportunities using the Internet requires business strategies to be 
developed and implemented in Internet time, and the triumph of speed 

20 over size is becoming more apparent every day. While the key drivers for 
B2B are speed and competition, collaboration between trading partners is 
the key to winning the game. Truly changing the rules requires real-time 
information exchange, transactional integrity, flexibility to adapt to changing 
market conditions, and integrated trading relationships between business 

25 partners. The stakes are high, and can make or break a company. The 

rules change daily, as every e-business executive can attest. These are the 
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real e-business challenges. Meeting these challenges requires a different 
kind of B2B technology that can meet the real demands of collaborative 
commerce. 

As disclosed herein the invention helps to define an open, 
5 standards-based, and scalable software platform for dynamic 

business-to-business collaboration. The software platform may be 
embodied in various forms of server product, referred to herein as a 
collaboration server, or may be incorporated into larger scale enterprise 
collaboration server products referred to herein as collaboration systems. 
10 The several benefits provided by the invention include a comprehensive 
conversation management capability, an Internet based standard, and a 
pluggable business logic and protocol support. 

A primary component of the collaboration system is the 
collaboration space (c-space). The c-space is an abstraction supporting a 
15 single business model, business message protocols, a secure message 
space, security policies, quality of service policies, and a registered set of 
business trading partners. The c-space contains message vocabularies, 
business process models, participant roles, and other e-market metadata 
that are essential to the creation, deployment, and ongoing maintenance of 
20 trading activities. 

Using the invention, a c-space owner can create any number of 
concurrent c-spaces, each supporting any number of trading partners. 
Within a c-space, the invention provides asynchronous XML messaging 
capabilities to allow loosely coupled communication between trading 
25 partners. 

The collaboration system further comprises a collaboration hub 
(c-hub). The c-hub is the execution engine of a c-space, allowing the 
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c-space owner and trading partners to create, route, and manage 
messages within the trading environment. The c-hub delivers powerful 
messaging services that are essential to ensuring the security, quality, 
relevance, and success of conversations across the c-space. 
5 Within the context of B2B e-commerce, well-defined and ordered 

sets of related messages are exchanged between trading partners. This 
collective set of messages or "conversation" involving two or more trading 
partners can often span days, weeks, or even months. As conversations 
and business processes are initiated, executed and completed, 

10 conversation management software tracks and manages these long-living 
conversations, ensures that they are completed, and orchestrates the 
overall process execution. 

Each conversation has a unique context that enables users to 
manage multiple, concurrent conversations taking place in the c-space. 

15 The collaboration system uses such context information to help ensure that 
messages from one conversation do not get tangled up with messages 
from another. For example, an individual trading partner may be 
requesting proposals or negotiating prices with multiple vendors 
concurrently, and must maintain the integrity and security of each 

20 interaction. 

In one embodiment, the invention comprises a collaboration hub for 
use with a collaboration system, comprising a hub transport for receiving 
messages from participants and sending messages to participants, a hub 
router for routing messages from a first participant to a second participant, 

25 a hub scheduler for scheduling the flow of messages between the hub 
router and the hub transport, a conversation manager for managing the 
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flow of messages between participants, and a repository for storing 
conversation management data. 

Brief Description of the Figures: 
5 Figure 1 is an illustration of a collaboration system in accordance 

with an embodiment of the invention. 

Figure 2 is an illustration of a network of collaboration partners in 
accordance with an embodiment of the invention. 

Figure 3 is a schematic of a control hub and trading partners in 
10 accordance with an embodiment of the invention. 

Figure 4 is an illustration of a c-space creation process. 

Figure 5 is a schematic of a collaboration system with hub and 
trading partner enablers in accordance with an embodiment of the 
invention. 

15 Figure 6 is a schematic of a c-hub in accordance with an 

embodiment of the invention. 

Figure 7 is a flowchart of a message flow process in accordance 
with an embodiment of the invention. 

Figure 8 is a schematic of a c-space in accordance with an 
20 embodiment of the invention. 

Figure 9 is a schematic of a conversation initiation in accordance 
with an embodiment of the invention. 

Figures 10-13 are message flow diagrams of an example 
conversation in accordance with an embodiment of the invention. 
25 Figure 14 is a schematic of a conversation termination process in 

accordance with an embodiment of the invention. 
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Figure 15 is an illustration of a workflow server design process in 
accordance with an embodiment of the invention. 

Figure 16 is an illustration of a workflow server run time process in 
accordance with an embodiment of the invention. 
5 Figure 17 is an illustration of a workflow and client interaction in 

accordance with an embodiment of the invention. 

Figure 18 is an illustration of a workflow and enterprise application 
interaction in accordance with an embodiment of the invention. 

Figure 19 is a schematic of a c-hub repository in accordance with 
10 an embodiment of the invention. 

Figure 20 is a flowchart of an enterprise-wide collaboration system 
deployment process. 

Figure 21 is a schematic of a c-hub in accordance with an 
embodiment of the invention, showing the XOCP routing and filtering 
15 mechanisms. 

Figure 22 is a schematic of an XOCP c-bridge in accordance with 
an embodiment of the invention. 

Figure 23 is a schematic of an XOCP c-gateway in accordance 
with an embodiment of the invention. 
20 Figure 24 is a schematic of an XOCP c-proxy in accordance with 

an embodiment of the invention. 

Figure 25 is an illustration of an XML workflow creation processing 
using Rational Rose. 

Figure 26 is an illustration of a "swim lane" workflow example in 
25 accordance with an embodiment of the invention. 
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Detailed Description of the Preferred Embodiment 

End-to-end integration is both an overall architecture and a series 
of IT solutions that address three key business issues: The integration of 
critical business information and logic that reside in enterprise production 
5 and legacy systems; the desire to incorporate Web-based e-commerce 
application; and the need to take advantage of integrated e-commerce, 
including the integration of business precesses with trading partners. 

There is a general desire in the industry to develop new 

10 infrastructures for new B2B capabilities referred to as collaborative 

commerce. Collaborative commerce resembles an interactive, managed 
conference call of buyers and sellers. Real-time conversations among 
trading partners allow them to actively negotiate and execute business 
transactions, not just pass along information. Each and every B2B activity 

15 should be manageable as a seamless, integrated, and secure business 

event, regardless of how long this business transaction takes, or how many 
business parties or IT systems are involved — internally or externally. 

The new economy has transformed traditional brick-and-mortar 
businesses into e-businesses, and this transformation directly affects the 

20 way companies collaborate with their customers as well as a multitude of 
trading partners. As such, e-business is of increasing importance to most 
companies from the corporation's business perspective, e-business 
collaboration among trading partners can help speed new products or 
services to market, improve customer service, reduce inventory and supply 

25 chain costs, and ultimately increase shareholder value. From a technology 
perspective, e-business extends the use of existing, proven IT systems and 

Attorney Docket No.: BEAS-01033US4 SRM/KFK 
kfk/wp/beas/1 033/1 033us4.app.wpd 



- 15- 

business processes to include external, disparate systems that are 
increasingly being accessed over the Internet. As a result, new groups of 
people, such as customers, suppliers, and distributors — who previously 
did not have access to these systems — are also directly exposed to the 
5 requirements and nuances of how these individual systems and business 
processes operate. But most importantly, access to these systems brings 
with it new access to information that was previously unavailable to all but 
insiders within an organization. With this information comes the ability to 
collaborate in ways and with partners that were previously unavailable to 

10 most parties. 

E-Business is a real-time entity: interactive, customer driven, and 
highly competitive. The e-business winner will be the company — or set of 
companies — that can quickly and efficiently deliver products and services 
to partners, customers and end users with tight integration at all points 

15 along the value chain. Today's market leaders recognize that e-business is 
about creating a value proposition so compelling and a business 
experience so immediate and efficient that all partners and suppliers make 
doing business over the Internet a standard part of how they do business. 
While the key drivers for B2B are speed and competition, 

20 collaboration between trading partners is the key to winning the game. 
Truly changing the rules requires real-time information exchange, 
transactional integrity, flexibility to adapt to changing market conditions, 
and integrated trading relationships between business partners. The 
stakes are high, and can make or break a company. The rules change 

25 daily, as every e-business executive can attest. These are the real 

e-business challenges. Meeting these challenges requires a different kind 
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of B2B technology that can meet the real demands of collaborative 
commerce. 

Good B2B infrastructure software should be readily configurable 
and rapidly deployable, while being part of a comprehensive and cohesive 

5 e-business solution. It should deliver time-to-market benefits now, with the 
ability to scale to meet future needs and interoperate with next generation 
applications. It should scale to handle any volume of B2B transactions, 
flawlessly and reliably, day-in and day-out, around the globe. It should 
enable a company to conceptually manage each and every collaborative 

10 commerce activity as a seamless, integrated and secure business event, 
making the firewall transparent to the business user while leveraging 
emerging Internet programming standards and security models to 
empower IT. Finally, this infrastructure should deliver new capabilities to 
dynamically add or change business partners on the fly, the power to 

15 model and manage partner relationships in all of their complexity, and the 
flexibility to enhance business processes to meet changing market 
conditions and customer demands. 

These are the technology requirements for executing collaborative 
commerce strategies — and this is the area the present invention targets. 

20 As disclosed herein the invention defines an open, standards-based, and 
scalable software platform for dynamic business-to-business collaboration. 
The several benefits provided by the invention include: 

1 . Rapid Time-to-Market: IT execution is critical to companies that 
25 must extend their business to trading partners. Whether integrating the 
supply chain or launching new e-market exchanges, companies need to 
get into the B2B game today with technology that is readily configurable for 
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rapid deployment— without the need for significant system re-writes, 
business process reengineering, or negotiation to install a common B2B 
partner application set. The solution should be easy and relatively 
inexpensive for partners to integrate in a non-proprietary fashion, with 

5 options for leveraging and extending existing investments in electronic 
data interchange (EDI), B2B applications, and emerging XML messaging 
standards such as RosettaNet. The system incorporating the invention is 
dynamic and simple to configure. Trading partners can be dynamically 
added and removed from the collaboration, helping to rapidly achieve the 

10 critical mass essential for marketplace initiatives — with the flexibility to 
make revisions as business models and partnerships evolve. Templates, 
easy-to-use graphical user interfaces designed for the business-level 
analyst, and configuration tools ensure that businesses can quickly design 
and execute mission-critical B2B processes. 

15 

2. Lowered Barriers-to-Entry: Trading partners can rapidly join and 
participate in an automated manner by simply downloading lightweight 
software which enables them to participate in trading activities. 
Additionally, the invention has been designed to provide support for 

20 multiple business protocols — to accommodate the diverse needs of 
multiple industries and diverse communities of trading partners. 

3. Reliable, Layered Messaging Platform: Companies typically 
go-to-market rapidly with their B2B strategies, gaining an initial 

25 e-business foothold and then implementing the rest of the technology in 
phases. Although time pressures are intense, IT recognizes that it is 
high-risk and costly to invest in piecemeal technologies from multiple 
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vendors that do not work together, cannot scale, and are not readily 
extensible. Individual e-business IT initiatives ideally fit into a single, 
comprehensive architecture that allows companies to get into the game 
quickly, yet be confident that they can successfully incorporate value-added 

5 business logic and build an integrated and high-performance B2B platform 
over time. To accomplish this, the invention provides a robust and reliable 
messaging platform designed specifically to meet the distributed, 
heterogeneous and loosely coupled nature of B2B e-commerce. Intelligent 
message routing and the ability to define the quality of service are an 

10 intrinsic part of the messaging platform. Additionally, a layered architecture 
provides a flexible means of adding new and emerging transport protocols 
to meet current and future requirements. 

4. Comprehensive Conversation Management Capabilities: 
15 Complex B2B relationships require open, standards-based process 
technology that reliably defines and manages the execution of 
cross-enterprise processes. This process architecture must respect the 
autonomy of individual trading partners, while allowing the definition and 
management of common process agreements across trading partners. To 
20 be effective, this technology must be flexible enough to manage 

system-to-system processes as well as seamlessly incorporate humans 
and real-world interactions into the process. Unlike most B2C transactions 
which may involve a limited number of participants over a limited number 
of days (and, in some cases, hours), well-defined B2B interactions or 
25 "conversations" between trading partners may take weeks or even months 
to complete and may involve numerous participants. To meet these 
requirements, the invention may utilize a variety of sophisticated 
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messaging protocols, including the extensible Open Collaboration 
Protocol (XOCP) which provides life cycle management of long-living 
conversations, and ensures the overall execution and completion of 
business processes. 

5 

5. Single Process Platform: While B2B technology must be rapidly 
deployable; it must also be powerful and flexible enough to support 
changing processes, evolving partner relationships, and new business 
models. It must support a variety of configurations ranging from centralized 

10 e-market administration to distributed partner-centric workflow integration. 
It must be straightforward and enable the user to add and change 
relationships without bringing the system down or compromising the 
integrity of transactions that are in progress. Embodiments of the invention 
provide end-to-end e-process management by interfacing with other third- 
is party workflow products including the BEA WebLogic Process Integrator, a 
J2EE-compliant and XML-based process integration engine from BEA 
Systems Inc., San Jose, California. BEA WebLogic Process Integrator is 
one example of products that enable the effective, end-to-end 
management of system and application-based business processes, as 
20 well as traditional human-based workflow on both sides of a company's 
firewall. 

6. No Need for Business Process Reengineering: The invention 
enables the creation of one or many virtual trading communities on the 

25 Internet, connecting trading partners in a conceptually free-standing 

environment with its own defined business processes. This unique design 
reduces the need for business process reengineering, enabling disparate 
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trading partners to participate in public processes which take place within 
the e-market while allowing individual trading partners to define, implement 
and execute distributed, private business processes locally. 

5 7. Internet Standards-Based: B2B is most valuable and effective 

when it is fully integrated from the back-end systems and extends out 
across the firewall to trading partners, regardless of the disparate IT 
systems and processes employed. Adhering to open industry standards 
such as Java, XML, and HTTP on nonproprietary systems optimizes 

10 partners' ability to integrate seamlessly and quickly. Standards-based 

technology also allows IT to leverage existing skill-sets rather than being 
forced to invest in something that is proprietary and cannot be replicated. 
To ensure rapid, efficient integration of partners, embodiments of the 
invention use a standards-based architecture leveragls an HTTP 

15 communications protocol for information transportation over the Internet, as 
well as standards and concepts such as SSL, PKl and J2EE — reducing 
the need to dedicate internal IT resources to proprietary technologies. 

8. Security: With trillions of dollars at stake, B2B commerce 
20 systems must support high transaction volumes and varying levels of traffic 
and throughput. Furthermore, this IT infrastructure must be 100 percent 
reliable and ensure the integrity and security of all interactions. Today's 
e-business not only stakes millions in B2B infrastructure and applications, 
but also puts its reputation with trading partners and customers on the line. 
25 Thus, the technology must have a well-designed architecture, and be 

compliant with the full range of emerging Internet security standards. The 
invention provides a trusted and secure platform for conducting B2B 
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e-commerce, including built-in Internet security capabilities for data 
privacy, authorization, authentication, and an infrastructure to support 
non-repudiation. 

9. Pluggable Business Logic and Protocol Support: Embodiments 
of the invention provide a plug-in architecture for dynamic and intelligent 
routing of messages. This enables market makers to design and 
implement business rules that meet their specific needs. Additionally, 
multiple business protocols such as RosettaNet and EDI can exist 
concurrently in the same deployment — reducing the need for all trading 
partners to standardize on one particular protocol. The invention also 
provides a flexible framework for rapidly implementing custom business 
logic that may be required to maintain a competitive advantage. 

10. Proven, Scalable Technology: As B2B infrastructure vendors 
consolidate, it is increasingly critical to ensure that you will be fully 
supported by a strategic partner you can count on 24-hours a day, seven 
days a week, around the globe and well into the future. Embodiments of 
the invention can be designed to run on industry-leading transaction 
servers such as BEA WebLogic Server from BEA Systems, Inc., San 
Jose, California. 

1 1 . Interoperability: The invention uses an open and flexible 
architecture that can interoperate and leverage existing investments in 
EAI/B2B technologies as well as enterprise databases, Supply Chain 
Management (SCM), Customer Relationship Management (CRM), and 
mainframe systems. The invention also enables explanation of Common 
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Object Request Broker Architecture (CORBA), Enterprise JavaBeans 
(EJB), Tuxedo, and COM+ applications. This inherent flexibility provides a 
highly scalable and adaptable platform for the development and 
deployment of future B2B initiatives. 

5 

Glossary of Terms 

DUNS — Data Universal Numbering System. A distinctive nine-digit 
identification sequence that is an internationally recognized common 
company identifier in global electronic commerce transactions. 

10 

PIP — Partner Interface Process. A protocol provided by RosettaNet that 
specifies the business messages exchanged, their vocabulary, and how to 
validate them. A number of these protocols have been defined for various 
types of business transactions (e.g.: TransferShoppingCart, 
15 QueryOrderStatus, etc.) 

RosettaNet — Depending on its use in context, RosettaNet is either of the 
following definitions: An independent, non-profit consortium that is defining 
standard electronic business interfaces; or the business and transport 
20 protocol specified by this group. 

XOCP — XML Open Collaboration Protocol. A protocol used by the 
collaboration server that provides more complete life cycle and 
management support for business interactions. XOCP is described in 
25 more detail later in this document. 
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Collaboration System 

Roughly described, the invention comprises a collaboration server, 
which may itself be a component of a larger collaboration system. Figure 
1 shows an embodiment of the invention. As shown therein, 
a collaboration system in accordance with an embodiment of the invention 
includes a transaction in application server 102 operating as a base. 
Examples of transaction servers which may be used with the invention 
include the WebLogic Server product from BEA Systems, Inc., San Jose, 
California. The transaction server provides an application infrastructure 
upon which the collaboration system resides. Other transaction servers 
may be used. The application infrastructure ensures overall system 
availability, scalability, and security through the use of transaction 
processing, persistence, threading and components. 

Atop the collaboration system sits a business process and workflow 
server 104. Examples of workflow servers that may be used with the 
invention include the WebLogic Process Integrator product from BEA 
Systems, Inc. The workflow server allows a company to define their 
business processes as a workflow. The workflow may take into account all 
aspects of a company's business from start to finish, including, for 
example, manufacturing processes, purchasing, sales, financial 
processes, etc. A key attribute of a workflow is that it be dynamic, flexible 
and configurable, i.e. that it may be readily modified to reflect a company's 
changing business model, to add new elements such as new product lines, 
and to account for new events as they occur. The workflow server also 
acts as an interface for a company's business application to plug into and 
utilize the workflow. Business application may include, for example, 
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catalog management 106, dynamic pricing 108, order management 110, 
logistics 1 12, and payment applications 114. 

In one embodiment of the invention, sandwiched between the 
application infrastructure server and the workflow server lies the 

5 collaboration server 116. The collaboration server is a key component in 
creating a collaboration system, and in bringing workflow management to 
the enterprise. The collaboration server allows separate companies, 
herein referred to as trading partners, to collaborate on complex tasks or 
projects. Such collaboration may extend, for example, to complex 

10 business projects, manufacturing processes, or logistical tasks 

encompassing many companies spread over many countries. As such, 
the collaboration server acts as part of a collaboration system to allow 
globally dispersed trading partners to share information and resources, 
and to work towards a common goal. 

15 A key attribute of the collaboration server is the ability to interface 

with workflow processes running on a workflow server. To this end the 
collaboration server must be able to control the flow of information into and 
out of the workflows maintained by the workflow server. For collaboration 
among different companies the collaboration server must be able to do 

20 this for many workflows, and many workflow servers, and must be able to 
perform this task simultaneously, equally, and reliably. The collaboration 
server of the invention does this by means of a sophisticated routing and 
filtering mechanism. Messages from different trading partners, or in some 
instances the workflows of different trading partners, are filtered by the 

25 collaboration server, and routed to the appropriate recipients in a true 
collaborative fashion. 
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Figure 2 illustrates a real-world example of how the invention may 
be used. As shown in this particular example, a manufacturer may employ 
the invention to create a collaboration system. The manufacturer 122 is 
responsible for maintaining and administering the system which may 

5 include an application server, a workflow server, and a collaboration 
server. In combination, these collaborative components may act as a 
trading hub or clearing house for trading partners to collaborate with the 
manufacturer. As shown in Figure 2, suppliers 124 and distributors 126 
that act as trading partners with the manufacturer may participate in the 

10 collaborative process. Each of these entities may have their own workflow 
servers and workflow processes that may interact with the manufacturer's 
workflow process. Other entities, for example a logistics partner 128, may 
participate in the collaboration system without any need for their own 
workflow server. As may be seen, a particular entity or trading partner 

15 need not have its own workflow process to take part in a collaboration 

system, but in those instances where the trading partner does have its own 
workflow, the invention can make use of it and integrate (at least portions 
of) it into the collaborative enterprise workflow. 

Figure 3 shows an initial step in preparing the invention for use in 

20 an enterprise. A company wishing to use the collaboration system must 
first develop a central point 132 or hub at which to build the collaboration 
system, and identify the trading partners 134, 136, 138 that will participate 
in the collaboration system. Typically, the hub is developed and 
maintained by a large manufacturer who may wish to streamline their 

25 materials procurement and manufacturing processes, but the invention is 
not limited to such users, and indeed the collaboration system and c-hub 
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may be built by any entity including suppliers, resellers, distributors, 
logistics providers, purchasers, market makers, e-portal providers, and 
others. The trading partners may likewise be any of these entities or 
anyone else interested in participating in a complex e-commerce business 
5 project. 

The development of the collaboration space is shown in Figure 4. 
A company must first decides on the business purpose of the c-space, 
define a vocabulary, and a set of protocols, and provide a specification. 
Figure 5 shows the installation of the c-space into the collaboration 

10 system. The central collaboration provider installs a collaboration hub, or 
c-hub 154, most likely at their place of business but the c-hub can be 
installed anywhere geographically, such is the benefit of a global 
e-commerce solution. The c-hub controls a collaboration space, or c- 
space 156 - an abstract structure wherein collaboration messages are 

15 transmitted back and forth between trading partners in a continuous 

conversation-like manner. Trading partners use collaboration enablers, or 
c-enablers 158, software applications allowing them to send messages to, 
and receive messages from, the c-hub. The enablers may also interface 
with workflow processes and servers at the trading partners' location so 

20 that such messages are generated and received automatically. The 

messages can be in any format - the invention is designed to be flexible in 
the type of messaging the c-hub understands. For standardization 
purposes and to ensure the widest usage of the invention, in one 
embodiment industry standard XML messages can be used. The enabler 

25 may then send and receive such XML messages to and from the c-hub by 
any convenient means, including the Internet. In this manner the invention 
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allows geographically distant trading partners to communicate workflow 
processes easily, with minimal communication cost, and with little or no 
change in their current workflow technology. 

5 Collaboration System Architecture 

In one embodiment the collaboration system may utilize many 
components, including: 

• a c-hub 

• a c-space 

10 • a conversation manager 

• a c-space enabler (enabler) 

• a workflow integrator (workflow server) 

Not all of these components need be installed centrally, on the 
15 same server, and indeed the c-space enabler is more likely to be installed 
at a remote trading partner location than at any central hub location. The c- 
space enabler, or simply the enabler, is however an important part of the 
enterprise-wide collaboration solution. Other components, such as the 
workflow integrator are optional, and while not necessary for participation 
20 in the collaboration network, greatly increase the potential benefits to any 
company or participant using a workflow to model their business 
processes. 

Collaboration Hub (C-hub) 

25 The c-hub is the centerpiece of the collaboration server. It is 

responsible for routing messages between various c-enabler components 
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and for managing the lifecycle of the various conversations between the 
participating trading partners. The invention uses a c-hub which provides 
the following functionality: 

• A modular hub: The c-hub allows for the easy addition of code at 
various well-defined points. 

• Logic Plug-Ins: At well-defined plug-in points, customers may be 
allowed to introduce their own code. These plug-ins, referred to as 
"Logic Plug-Ins", allow the customer to provide additional 
processing of the information passing through the c-hub. 

• Protocol Plug-ins: An extended type of Logic Plug-In is a "business 
protocol plug-in", which provides support for various business 
protocols other than the out-of-the-box XOCP support such as the 
RosettaNet router. 

• URLs for c-spaces: To support the use of c-spaces by non-XOCP 
business protocols, in one embodiment all c-spaces require a 
unique URL per business protocol supported by that c-space. This 
allows the c-hub to unambiguously identify the proper c-space and 
business protocol of incoming messages. 

• RosettaNet Protocol Plug-in: A special business protocol plug-in 
that allows the c-hub to function as a router for RosettaNet 
(non-XOCP) business conversations. 

Figure 6 shows the c-hub architecture, as well as the normal flow of 
business messages through the c-hub: This is a somewhat simplified 
layout that will be expanded upon later. However, it provides the overall 
picture of the c-hub. The important points to note are: 
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• The central c-hub components (transport 174, scheduler 178, and 
router 182) make up an integrated infrastructure. 

• The decoder 1 76, encoder 1 86, conversation manager 1 90, and 
repository 192 components may be made available for customers 
to change or access. 

• The router 1 80 and filter 1 84 components are customizable by the 
customer. The invention provides default implementations for 
XOCP and RosettaNet support. 

• Multiple components (or "chains") in each quadrant are allowed. 

The message flow through the c-hub begins with an incoming 
message 172 from a trading partner via proceeds to the hub router, and 
then proceeds down as an outgoing message 188 to the recipient trading 
partner or partners, as indicated by the arrows. The two sides of Figure 6 
are usually described from the perspective of the client or trading partner 
and are herein referred to as the publish side (left side) and receive side 
(right side). 

The main characteristics and contractual obligations of each 
component are illustrated in the flowchart Figure 7 and can be 
summarized as follows: 

1 . The C-hub Transport 1 94: 

The incoming message is read and routed to an appropriate 
decoder chain based on the message protocol (e.g.: XOCP, RosettaNet, 
cXML, etc.). In one embodiment, that defines c-spaces in terms of URL's, 
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the URL on which the message is received serves to identify both the 
protocol being used and the destination c-space. 



2. The Decoder chain 1 96: 

5 Any protocol-specific headers in the message are processed by 

the decoder and the appropriate business protocol handler is assigned. 
The sending trading partner is also identified. The sending trading partner 
is then enlisted in a conversation, and a reply is prepared to be returned to 
the sender. 

10 

3. The C-hub Scheduler 1 98: 

The message is stored for subsequent retrieval. 

4. The Router Chain 200: 

15 The trading partners to whom this message should be routed are 

determined. Logic Plug-Ins can add or remove recipients from this list. 

5. The C-hub Router 202: 

Final validation of the message recipients is performed, and the 
20 message is stored for delivery to the targeted trading partners. 

6. Filter chain 204: 

A message destined for a single trading partner recipient is 
received and a decision is made on whether to send the message. Filter 
25 logic plug-ins may be used to add or remove this message from this 
recipient's receive mechanism. 
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7. The C-hub Scheduler 206: 

Internal operations relating to quality of service issues, conversation 
management, etc. are performed if the message is still schedules for 
sending to a recipient. 

8. Encoder chain 208: 

The encoder performs any transportation of the message required 
to support the business protocol of the recipient. 



10 9. C-hub Transport 210: 

The C-hub transport layer sends the message to the trading partner 
recipient. 



For each module chain, the main responsibility is as indicated 
15 above. This contract must be fulfilled in order to ensure proper message 
processing and delivery. As long as the contract is fulfilled, other modules 
in the chain are relatively unencumbered in terms of the processing that 
they may be required to provide. 



20 Collaboration Space (C-space) 

A primary component of the invention is the c-space. Figure 8 
shows an example of a c-space 212 shared by many buyers, sellers and 
other entities. The c-space is an abstraction supporting a single business 
model, business message protocols, a secure message space, security 
25 policies, quality of service policies, and a registered set of business 

trading partners. The c-space contains message vocabularies, business 
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process models, participant roles, and other e-market metadata that are 
essential to the creation, deployment, and ongoing maintenance of trading 
activities. 

Using the invention, a c-space owner 214 can create any number of 
5 concurrent c-spaces, each supporting any number of trading partners. 
Within a c-space, the invention provides asynchronous XML messaging 
capabilities to allow loosely coupled communication between trading 
partners 216, 218. This model leverages routing and filter functionality that 
can be associated with messages in order to classify the set of trading 

10 partners that should receive a message, allowing partners and their 
interactions to be managed individually, based on their role or trading 
preferences within an e-market. 

The c-hub is the execution engine of a c-space, allowing the 
c-space owner and trading partners to create, route, and manage 

15 messages within the trading environment. To facilitate the execution of 
business transactions across a disparate base of trading partners, one 
embodiment of the invention uses XML as its e-business messaging 
semantic. Figure 5 shows some XML transfer paths between trading 
partners (using c-enablers), and a trading hub hosting a c-space. 

20 Within, as well as outside of a c-space, XML offers tremendous 

advantages as a universal format for messages passed between trading 
partners because it provides a common syntax to structure information. 
However, XML by itself doesn't solve the interoperability problem, as 
collaborating entities must agree on the semantics of business protocols 

25 for this information. The invention is independent of business protocol 

message vocabulary, so it can support any standards-based or proprietary 
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business protocol or vocabulary. As such the invention delivers the ability 
to support multiple protocols within the same c-space as well as to extend 
a c-space through supplemental protocol handlers or business logic 
plug-ins. 

5 Within the context of B2B e-commerce, well-defined and ordered 

sets of related messages are exchanged between trading partners. This 
collective set of messages or "conversation" involving two or more trading 
partners can often span days, weeks, or even months. To manage these 
unique conversations, embodiments of the invention implement an 

10 extensible Open Collaboration Protocol (XOCP), which provides the 

ability to specify both the information (vocabulary) and business protocol 
(process flows) for a given conversation. As conversations and business 
processes are initiated, executed and completed, conversation 
management software tracks and manages these long-living 

15 conversations, ensures that they are completed, and orchestrates the 
overall process execution. 

The invention allows the powerful business process management 
and workflow capabilities of workflow server products such as BEA 
WebLogic Process Integrator to provide the infrastructure to facilitate 

20 conversations within the c-space. The innovative architecture allows each 
trading partner to handle the implementation of their own business process 
and rules locally, while conforming to the rules of engagement (defined by 
the global information and business protocols) for a given c-space. 
Features include: 

25 • Transport-protocol independent (for example http/https) 

• Business-protocol independence (cXML, BizTalk, RosettaNet or 
any proprietary business documents) 
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• Definition of conversations including process and vocabulary 
definition 

• Allows definition of quality of service (QOS) parameters for a 
message (e.g. guaranteed delivery) 

5 • Provides a mediated messaging model, with support for both 

publish and receive filters 

• Supports user-defined message routing and filtering 

• Flexibility to apply message or data content transformation 

10 Given the complexity, duration, and volume of business transactions 

required between trading partners conducting collaborative commerce, an 
effective solution must provide functionality to address these specific 
requirements. Unlike traditional solutions, the invention provides a unique 
approach to managing on-going interactions between individual trading 

15 partners as well as the context of each conversation within a c-space. 

Conversation Management 

Within the context of B2B e-commerce, well-defined and ordered 
sets of related messages are exchanged between trading partners. This 

20 collective set of messages or "conversation" involving two or more trading 
partners can often span days, weeks, or even months. To manage these 
unique conversations, embodiments of the intention provide a collaborate 
system that implements the extensible Open Collaboration Protocol 
(XOCP) described in further detail below, which provides the ability to 

25 specify both the information (vocabulary) and business protocol (process 
flows) for a given conversation. As conversations and business processes 
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are initiated, executed and completed, Conversation management 
software tracks and manages these long-living conversations, ensures that 
they are completed, and orchestrates the overall process execution. 

Within the collaborative system defined by the invention the powerful 
5 business process management and workflow capabilities of workflow 

products and workflow servers such as, for example, the BEA WebLogic 
Process Integrator provides the infrastructure to facilitate conversations 
within the c-space. Additionally, the invention's innovative architecture 
allows each trading partner to handle the implementation of their own 

10 business process and rules locally, while conforming to the rules of 

engagement (defined by the global information and business protocols) for 
a given c-space. 

Conversation context is another important aspect of managing 
conversations within a given c-space. Each conversation has a unique 

15 context that enables users to manage multiple, concurrent conversations 
taking place in the c-space. The collaboration server uses context 
information to help ensure that messages from one conversation do not 
get tangled up with messages from another. For example, an individual 
trading partner may be requesting proposals or negotiating prices with 

20 multiple vendors concurrently, and must maintain the integrity and security 
of each interaction. 

Figure 9 illustrates a schematic of a conversation lifecycle as 
managed by the conversation manager. The conversation process is 
dictated by the actions of three types of participants - conversation 

25 initiators, conversation terminators, and regular conversation participants. 
These roles are fully interchangeable in that a conversation initiator (an 
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initiator) may also act as a conversation terminator (a terminator). Regular 
conversation participants may become terminators, and so on. 
Collectively these participants are known as collaborators. Conversations 
between and amongst the collaborators creates the e-commerce 
5 collaboration environment. 

As shown in Figure 9, the conversation is first started or initiated 
234 by an initiator 232. The conversation then enters an active phase 
236. During this phase the actual process of message sending, routing 
and receiving takes place among the conversation participants. The 

10 conversation flow is coordinated by a conversation manager. This role 
may be played by any of the participants but is usually played by the 
central participant who is typically also responsible for managing the c-hub 
and the c-space. The conversation manager is responsible for generating 
conversation id's, registering participants in the conversation, maintaining 

15 the status of the conversation, and delivering conversation abortion or 

termination messages. As shown in Figure 9, a conversation may end by 
any of three means - either the conversation is aborted 238, perhaps due 
to error, or a change in conversation criteria; timed-out 240 due to the 
conversation period extending beyond its scheduled timeframe; or 

20 terminated due to the conversation having achieved its end result 242. 

Figures 10-13 illustrate possible steps in the lifecycle of a typical 
conversation. In Figure 10 the conversation is initiated by an initiator 250. 
The initiator must begin the collaboration process, start a new 
collaboration life cycle 258, initiates the flow of messages among the 

25 c-space, and then starts the execution and publishing 264 of such 
messages so that other participants may join in the conversation. 
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Figure 1 1 illustrates how a participant joins in the conversation. 
Having received the first message 268 from the initiator, via the c-space, 
the participant decides to join in the conversation 272, again through an 
execute and invoke process. From that point on the participant receives 

5 all published messages 280 from the conversation manager that are 
intended for delivery fo that particular participant. 

Figures 12 and 13 illustrate two alternate means for finishing a 
conversation. In Figure 12 the terminator communicates to the message 
publisher that the conversation should be terminated 284. The 

10 conversation manager clearly kills the conversation and notifies the 

participants accordingly 288. Figure 13 shows an alternate means of 
finishing a conversation in which a participant requests that the 
conversation be aborted 294. The conversation manager then 
coordinates sending abort messages to all the participants. Abort 

15 messages may be sent via a publisher under coordination of the 
conversation manager. 

A primary difference between the two means of conversation 
finishing illustrated in Figures 12 and 13 is that conversation termination 
normally occurs as a result of a successful outcome to the conversation 

20 among the conversation participants, whereas conversation abortion is 
usually used as an instantaneous interruption mechanism that does not 
normally produce a successful outcome. Figure 14 illustrates a 
compensation mechanism that may be used to rectify unsuccessful 
outcomes of aborted conversations. A business compensation routine 

25 308 is used to signify that two participants 302, 304 may participate in a 
conversation on an equal basis, i.e. they provide equal input to the 
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enterprise workflow. If one participant which is currently taking part in a 
conversation receives a conversation abort message 306, the 
compensating participant may take its place, depending on the reasons 
that caused the original abort message. If the entire conversation was 
5 aborted, then there may be no conversation for the compensating 
participant to join. 

URL Accessible C-spaces 

C-spaces are a useful, but generally XOCP-specific, concept. 

10 Most existing standard business protocols like RosettaNet and cXML do 
not use the concept of c-spaces or partitioning. Many of these protocols 
are point-to-point oriented, and do not even have the concept of multi-cast. 
To increase accessibility and ease of integration, embodiments of the 
invention preserve the c-space concept for XOCP, and introduce it for 

15 non-XOCP business protocols. In order identify a particular c-space and 
a business protocol, each c-space/business-protocol combination may 
have a unique uniform resource locator (URL). A client can use this URL 
in order to access a particular c-space using a particular business 
protocol. This also allows a single c-space to support multiple business 

20 protocols by using multiple URLs. 

A c-space might have more than one URL to help identify special 
additional processing that may be required to support multiple business 
protocols or to handle variations in business protocol implementations. 
For example, a c-space may have a RosettaNet orientation, but 

25 participants may be using RosettaNet implementations from different 

vendors. Variations in the different implementations can affect how the 
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decoder needs to process the information for routing purposes. One way 
to handle such a situation is to have a single decoder try to apply some 
heuristics to determine from which protocol variation a message is being 
received, and then process the message accordingly. 
5 An alternative solution is to have the c-hub provider assign a 

separate URL for clients using each of these variations within a single 
c-space. In this approach, each message can then be routed to the 
specific Decoder that knows exactly how to handle the type of message 
being received. 

10 Through the use of different URLs, a single c-space can support 

multiple protocols. These protocols can be quite dissimilar (e.g.: 
RosettaNet and XOCP). 

Collaboration Enabler 

15 In accordance with one embodiment of the invention a 

Collaboration Enabler (c-enabler) is a lightweight, readily downloadable 
software that enables a trading partner to participate in a c-space. A 
trading partner must be identified and authorized by the c-space owner or 
administration in order to activate the c-enabler and actively participate in 

20 a c-space. One of the security protocols supported the system is the 

X.509 certificate, which can be authorized by the c-space administration 
and granted by a Certificate Authority. The trading partner can then be 
authorized by the c-space administration (based on conversation types, 
business documents, and roles) to participate in a particular c-space. Like 

25 the c-hub, the c-enabler can easily integrate with applications running on 
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other application servers and reduces the barrier-to-entry for trading 
partners who want to participate in the c-space. 

In one embodiment, the minimum configuration requirement to run 
the c-enabler maybe designed to run on a servlet engine, for example the 
5 BEA WebLogic Express servlet engine. For complex B2B scenarios, 
many organizations may benefit from the use of a robust process 
management tool such as BEA WebLogic Process Integrator, a workflow 
server and integration product described in detail below, which runs on 
BEA WebLogic Server. 

10 

Workflow Integration 

Workflow products and servers may be integrated with 
embodiments of the invention to manage complex e-business processes 
between multiple trading partners. Together they provide a federated 

15 process model among trading partners, where market processes are 

defined globally but deployed in a distributed manner with local processes 
being modeled and executed at each trading partner's site. The invention 
provides the overall management and coordination of these distributed 
processes as part of the product's conversation management functionality. 

20 Workflow server products such as BEA WebLogic Process 

Integrator from BEA Systems, Inc. provide the ability to graphically model 
partner-based business processes. This tool also provides graphical 
design functionality for open business processes such as RosettaNet 
Partner Interface Processes (PIPs), which govern processes across the 

25 global information technology supply chain. RosettaNet PIPs enable 
companies to deploy standards-based, interoperable applications for 
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supply-chain functions and to optimize networks of suppliers, 
manufacturers, and distributors. 

While collaborative commerce is driven by the desire to automate 
and streamline e-business processes, one can not completely eliminate 

5 the ability to involve humans in the execution of e-business processes. 
Unlike other B2B platforms, the invention's process capabilities provide 
the ability to define and direct e-business process exceptions to human 
users for resolution. The combination of a collaboration server and a 
workflow server in one collaboration system also delivers unparalleled 

10 flexibility to drive and integrate cross-enterprise collaborative processes, 
enterprise applications, 

and transactions on either side of the firewall using a single process 
technology. 

15 Integration Server 

Figure 15 illustrates schematically the architecture of a typical 
workflow server. Although the workflow server shown here is a Weblogic 
Process Integrator server from BEA Systems, Inc., the key elements are 
common to many workflow server, and the invention is flexible enough to 

20 work with any similar product. As shown in Figure 15, the workflow server 
must first be initialized (at design time) to have a workflow. This is 
typically done by creating a new workflow template 320, and using this 
template to define an XML document 322. The company then defines a 
set of business operations 324 and stores these with the templates in a 

25 workflow template database 326. 
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At run time, shown in Figure 16, enterprise applications start 
workflow instances based on the saved workflow templates. The workflow 
server executes these instances to effect the workflow 330, and as a result 
affect other business operations, enterprise applications and backend 
5 systems. The workflow instances, and hence the communications 

between the enterprise applications and the workflow server, use an XML 
format. This allows for portability and ease of integration with other 
systems. 

The workflow server process engine 340 may thus communicate 
10 directly with a worklist client, shown in Figure 17. This may be a local 
application working within the local workflow and accepting or sending 
workflow process messages directly to the workflow. The workflow server 
process may also communicate with enterprise components 342, using 
XML 

15 344, RMI and EXEC, among others. As shown in Figure 18 the workflow 
server 340 includes the ability to both send and receive XML messages 
346 related to its workflow. This is how it communicates with the 
collaboration server, or the collaboration system as a whole. More 
particularly, the workflow server can pass messages to the c-enabler by 

20 XML, which then communicates these messages to the c-hub. Messages 
from the c-hub are then similarly passed by the c-enabler to the workflow 
server, again in XML format. In this manner, not only can the workflow 
server affect the enterprise workflow operating on the enterprise level, but 
the enterprise level workflow may also affect the workflow operating at the 

25 local level. This is the true measure of collaborative e-commerce. 
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Business Protocol and Logic Plug-Ins 

Evolving business models on the Internet require the flexibility to 
measure business performance in many different ways. Business Logic 
Plug-Ins allow the c-space owner to add unique functionality to a c-space 
5 such as auditing, billing, or invoking complex business rules. For 

example, the c-space owner may have a business model that requires 
them to bill or audit based on the content, volume, number of recipients, 
etc. of messages, which have been mediated by a c-space. 

Additionally, while the Internet has provided companies with the 

10 ability to do business with nearly anyone that they want to — this might not 
always be desired. Using the Business Logic Plugins and complex 
business rules, filtering functionality can be used to enable individual 
trading partners to decide whether or not they want to receive a particular 
message (or perhaps any message) from a particular trading partner. For 

15 example, a trading partner may not want to receive a "request for 

proposal" message for fewer than 5,000 units. In this case, a filter would 
be used to reject any request for 4,999 or fewer units. Conversely, routing 
functionality can be used by a c-space owner to add to or delete trading 
partners from the recipient list for a particular message. This could be 

20 used to tailor the list to a relevant, desired set of recipients — or expand it 
in order to increase the chance of finding an appropriate "buyer" or 
"seller". 

Logic Plug-ins 

25 Logic Plug-Ins is the term used to describe the individual 

components or modules in the chains shown in the preceding c-hub 
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architectural overview. Each chain, as a whole, has an obligation to 
satisfy its respective contract, described earlier. However, as long as the 
contract is satisfied, the other modules in the chain are free to do 
additional processing. 

Logic Plug-Ins can be "chained" so that, after one Logic Plug-In is 
finished running, the next sequential Logic Plug-In of this type will normally 
be activated. Each successive Logic Plug-In will be able to access the 
changes, if any, to modified message information. 

The following list illustrates the types of additional processing 
(sometimes referred to as rules) that can be performed by modules in a 
chain: 



• Route modification 

• Content modification 

• Examination 

• The ability to "Reroute on Error" 



Publish-Side and Receive-Side filters (described in further detail 
below) are special route modification Logic Plug-Ins placed in the Router 
and Filter chains, respectively. Either the c-hub owner or the trading 
partner or both can specify these filters. The Publish-Side filter is used by 
the sending trading partner or the c-hub owner to specify a list of target 
trading partner recipients for the message being sent. This filter, a router 
Logic Plug-In, may add to, remove from, or not change the current list of 
recipients. This list of recipients is still subject to validation by the c-hub 
Router. The Receive-Side filter is used by the receiving trading partner or 
the c-hub owner to determine whether or not the message should be sent 
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to the specified recipient. It must provide a "yes" or "no" decision as to 
whether to send the document to the specified trading partner recipient. 

Business Protocol Plug-Ins 

5 Someone who writes a business protocol plug-in needs to 

implement the full suite of Decoder, Router, Filter, and Encoder Logic 
Plug-Ins in the c-hub. This is required in order to provide the message 
processing capabilities necessary to pass a message from a sender, 
through the c-hub, to zero or more recipients. In addition, a conversation 
10 manager is required to handle the basic message processing capabilities 
needed to route a message. A business protocol plug-in developer should 
provide: 

1. Protocol and Plug-In implementations: This will handle 

15 message-specific processing needs, such as finding the trading partner 
information in the message. 

2. A conversation manager implementation: This will handle 
conversation needs, such as finding out whether there are any recipients 

20 available for the given message. 

3. Repository information: The c-hub repository will need to have 
information that allows the protocol plug-in to provide the necessary 
support, including such things as conversation names, DTDs, business 

25 identifiers, and so on. 
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Repository 

The c-hub stores all the information it needs to manage a c-space 
in a c-hub repository. Figure 19 represents the c-hub repository needs as 
a hybrid based on a block layout that is repository-oriented. This indicates 
5 the type of information required to configure the c-hub in order to provide 
support for multiple protocols within a c-space, URLs for protocols, and 
Logic Plug-Ins. This information may include the c-hub 510, the c-space 
512, the business protocol used 514, the conversation identifier 516, the 
sender identifier 518, the trading partner identifiers 520, 524, together 
10 with any extended property sets 522, 526, the message identifier 528, and 
in some instances a portion of the message itself 530. 

The fields used in one embodiment of the invention include the 
following: 

15 

//c-hub/cspace/business-protocol : 

Each c-space supports one or more identified business protocols. The 
name is a logical name for a protocol defined in the Business Protocol 
Def. 

20 

/ /c-hub/ cspace/business -protocol @url : 

Each business protocol must specify a URL to be used to connect to the 
decoder for that c-space. 

25 //c-hub/business-protocol-def : 

The definition of a business protocol that is used in one or more c-spaces. 

/ /c-hub/business-protocol -def /decoder : 

This specifies the chain of decoders to be used when processing a 
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message. These are logical names for Logic Plug-Ins defined elsewhere. 
At least one of these is responsible for fulfilling the responsibility for this 
type of Logic Plug-In and this business protocol. The Logic Plug-Ins in the 
chain will be processed in the specified sequence. 

5 

/ /c -hub/business-protocol -def /router : 

This specifies the router chain, which is analogous to the decoder chain 
described previously. 

10 //c-hub/business-protocol-def /filter : 

This specifies the filter chain, which is analogous to the decoder chain 
described previously. 

//c-hub/business-protocol-def /encoder : 

15 This specifies the encoder chain, which is analogous to the decoder chain 
described previously. 

//c-hub/business-protocol-def /java- class : 

The Java class specifying the implementation of this particular protocol. 

20 

//c-hub/business-protocol-def /init-params : 

When the business protocol is loaded and initialized, its init(...) method 
will be invoked with a hash table of the name-value pairs specified in the 
following elements. 

25 

//c-hub/business-protocol-def /init-params /name : 

The "name" part of a name-value initialization pair. 
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/ /c-hub/business-protocol-def /init-params/value : 

The "value" part of a name-value initialization pair. 

//c-hub/user-exit-def: 

5 This provides a concrete definition for a Logic Plug-In specified by a 
logical name. 

/ /c-hub/user-exit-def /document : 

Zero or more DTDs used by the Logic Plug-In. These are the logical 
10 names for DTDs defined elsewhere in the Collaboration Server repository 
as Documents. The main decoder Logic Plug-In will frequently require one 
or more DTDs for non-XOCP protocols. 

//c-hub/user-exit-def / java-class : 

15 The Java class specifying the implementation of this particular Logic 
Plug-In. 

//c-hub/user-exit-def /init-params : 

When the Logic Plug-In is loaded and initialized, its init(...) method will be 
20 invoked with a hash table of the name-value pairs specified in the 
following elements. 

/ /c-hub/user-exit-def /init-params /name : 

The "name" part of a name-value pair. 

25 

//c-hub/user-exit-def /init-params/value : 

The "value" part of a name-value pair. 
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/ /c-hub/ trading-partner-protocol : 

Additional trading partner information needed for non-XOCP business 
protocol support. 

5 / /c-hub/ trading-partner-protocol /external-url : 

An external URL to where messages should be routed (business 
message and replies). 

//c-hub/ trading-partner-protocol /business -identif ier : 

10 A business identifier to be used by an external trading partner, distinct 
from the internal The Collaboration Server trading partner name. 

//c-hub/ trading-partner-protocol /business -identif ier /type : 

The type of the business identifier. For example, for RosettaNet, a 
15 "DUNS" number is used. The type names are under control of the c-hub 
administrator and need to be synchronized with the related business 
protocol plug-in. 

//c-hub/ trading-partner-protocol /business-identifier/value : 

20 The value of the business identifier, correlated with the business type 
described earlier. For example, a "DUNS" identifier is a 9-digit number. 

Deploying the Collaboration System 

The invention provides a comprehensive infrastructure that meets 
25 the rigorous technology standards for B2B e-commerce, but keeps the 
barrier to B2B low for you and your business partners. The following 
section outlines how a company can rapidly create a c-space and 
transform traditional trading partners into co-collaborators, using the 
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invention. Figure 20 summarizes the steps required. 



1 . E-Business Strategy 380: First, based on an e-business strategy, a 
company must determine the types of business transactions to be 

5 conducted and the number of participants or trading partners necessary to 
achieve critical mass for a c-space. At this point, as owner of the c-space 
they (the company) identify the trading partners desired for the 
collaboration, and select the business and information protocols that will 
be supported. 

10 

2. Install the collaboration system 382: The company can then install 
and configure the c-space hub, and establish one or more XML protocols 
that will be used to facilitate conversations between the trading partners. 
For instance, they might choose a custom vocabulary and/or an emerging 

15 industry standard, such as RosettaNet. 

3. Define the Collaboration Process and Trading Partner Roles 384: 
Next, the c-space owner defines the collaboration process, or the means 
in which transactions will be conducted. Outlining "collaborations" involves, 

20 in essence, defining the inter- and sometimes intra-company process 
flows and transaction behavior that will take place within the c-space. 
Once this is defined, the trading partner roles for that particular 
conversation ("buyer" or 

"seller") are established. The business process models for each role may 
25 then created using the graphical design tools provided by the invention. 
Once the roles have been established, the types of messages that each 
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trading partner can receive can be configured. 

4. Test and Deploy the C-space 386: If all components are 
implemented successfully, the c-space is established and goes live. 

5. Downloading the C-enabler 388: Once the business-level 
relationships are established with trading partners (negotiated in parallel 
to steps 1-4), trading partners are able to download lightweight c-enabler 
software, begin the configuration process, and work to understand the 
processes of a particular c-space. As a part of the configuration, the 
trading partner must install an X.509 certificate provided by an 
independent Certification Authority. 

6. Request Authorization 390: Once a c-enabler is operational, the 
trading partner requests and is granted access to particular 
conversations. At this point, the trading partner may obtain, from the 
c-space owner, the process model for their respective role in the c- 
space's global business process. Execution of local process models can 
also be provided by workflow products such as BEA WebLogic Process 
Integrator. Each trading partner has the option to configure the local 
aspects of how BEA WebLogic Process Integrator operates, which may 
include the execution of actions, routing exceptions to humans or 
integrating to other enterprise systems. 

7. Begin Trading Activities 392: Once local business rules, 
processes, and actions have been identified and implemented locally at 
the trading partner's site, the trading partner is ready to begin trading in 
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the c-space and to receive messages relevant to their role in the various 
processes. The invention provides the c-space owner with the capabilities 
to add or remove trading partners and re-configure conversation 
parameters on-the-fly without disrupting the system. 

5 

Security and Administration 

The privacy, security, and verification-of-receipt capabilities of B2B 
technologies must enable users to maintain proprietary business 
practices, meet ongoing business demands and maintain an advantage 
10 over their competitors. To support these requirements the c-hub can be 
configured to support a comprehensive set of Internet security features, 
including: 

Privacy: SSL support for ensuring privacy of data over the Internet. 

15 

Authentication: Mutual authentication, where trading partners and the c- 
hub authenticate each other before allowing participation in dynamic 
collaboration activities. Authentication is based on X.509 certificates 
obtained from a trusted, third-party Certificate Authority. 

20 

Authorization: Access Control Lists and a role-based conversation 
participation mechanism to ensure authorized access to e-business 
collaborations and the corresponding messages that exist within in a 
c-space. Trading partners are authorized for specific roles within a c- 
25 space which, along with filtering features, govern the types of messages 
they can publish and receive. 
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Nonrepudiation: In some cases, business rules require that a receiver of a 
business document or message has legally sufficient and persistent proof 
about the receipt, the content, and the sender of the document— similar to 
that of a registered letter or notary public in the off-line world. The 
invention the required infrastructure support for digital signatures, digital 
receipts, and secure auditing. 

Embodiments of the invention also include an administration 
console, that which allows the c-space owner or designated administrator 
to configure and manage services and c-spaces using a Web browser. 
Common administrative functions include managing trading partners 
(adding or removing trading partners, granting and revoking access to 
conversations, etc.), configuring messaging services, monitoring on-going 
conversations, browsing system status (interactions, message delivery, 
and logs), and generating activity reports. 

The administration console offers dynamic management 
capabilities, which enable the re-configuration of system services 
on-the-fly, and the addition of new trading partners without disrupting the 
system. In addition to the Web-based user interface, system management 
functions are available via administration messages— this allows for 
automated monitoring and error recovery, and for integration to third-party 
system management tools. 
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XPATH Filtering 

The c-hub routes business protocol messages that are sent 
between trading partners. The c-hub supports different business 
5 protocols, which can be generally classified as XOCP protocols or 
external protocols: 

XML Open Collaboration Protocol (XOCP) is one of the default 
protocol used by the invention. This protocol is sent and received by 
trading partners using the c-enabler API. It provides support for 
10 conversation life cycle tracking and the management of business 
interactions by a mediating c-hub. 

External protocols are business protocols that may be sent by other 
products and conform to other conventions or standards (such as a 
RosettaNet message from a Vitoria trading partner). The c-hub 
15 determines the business protocol to be processed based on the URL that 
is specified when a connection is initiated from a trading partner to the 
c-hub transport layer. 

In the XOCP protocol the routing criteria are specified in a 
separate header of the message protocol. The sender can specify an 
20 XPATH router as a component of the message. This XPATH router is a 
string expression that specifies the intended recipients of the message in 
a very flexible manner using the XPATH syntax. The c-hub evaluates this 
XPATH expression after it receives an XOCP message from the sender. 
Thus, the XOCP protocol enables dynamic routing of the message to 
25 target recipients. 

The c-hub maintains contextual information about interactions 
between trading partners (also known as conversation coordination). The 
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XOCP protocol carries the information that enables the c-hub to monitor 
and maintain the status of the conversation and its participants. Before 
the c-hub retransmits an XOCP message to a set of target trading 
partners, it 

5 evaluates the XPATH expression against the set of trading partners 
configured in the repository to determine the routing of the message. 

The routing functions of the c-hub may be extended to support 
additional XPATH expressions defined in the repository, as well as 
user-defined extended properties that can be referenced to control the 

10 routing of messages. 

XPATH expressions for routing messages to trading partners is a 
special feature of the XOCP business protocol. When an application 
publishes a message using an external protocol (such as RosettaNet), the 
target recipient is explicitly encoded by the sender in the content of the 

15 message. Unlike the XOCP protocol, there is no concept of a mediating 
c-hub that can dynamically route the message to target recipients - both 
the sender and the target are completely specified by the external 
protocol. 

Figure 21 illustrates a high level overview of message processing 
20 and routing in the collaboration server c-hub. This section primarily 
addresses the XPATH routing and filtering aspects of the c-hub 
processing. 

The repository provides a pre-defined set of entity definitions (and 
associated properties) that support conversations between trading 
25 partners in a collaboration system using the invention. However, 
applications need to be able to extend these definitions so that 
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application-specific information can be modeled and stored in the 
repository. 

More specifically, the trading partner information in the repository is 
extended to support application-defined properties that can be associated 
5 with a trading partner. C-hub routing and filtering features can make use of 
these properties. These extended properties are organized by uniquely 
named extended-property-sets using the c-hub administration console and 
associated with one or more trading partners . 

The extended property sets are modeled in the repository so that 
10 they can be retrieved as subtrees within an XML document. These XML 
subtrees appear in the generated message-context XML document sent 
to the XPATH routers and filters. The XPATH expressions for the routers 
and filters can reference these extended properties. The root elements of 
each extended property set associated with a given trading partner will be 
15 inserted as the last children of the <trading-partner> element node. 

XPATH Routers 

C-enabler XPATH routers 402 - These are XPATH routers that are 
sent by an c-enabler application when publishing a message. The 

20 Conversation.publish() method allows a c-enabler application to specify 
an XPATH router expression when sending a message. This router 
contains an XPATH expression that selects a subset of <trading-partner> 
nodes from the message-context XML document generated by the 
repository. These XPATH router expressions can be extended so that 

25 c-enabler applications can select a set of trading partners by including 
references to application-specific extended properties. 
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Trading partner XPATH routers 412 - These are routers that are 
specified by a c-hub administrator in the repository and associated with a 
sending trading partner. These routers are similar to the c-enabler 
XPATH routers that are sent with a message, in that they use XPATH 
5 expressions to select a subset of target <trading-partner> nodes. For 

every message sent by a trading partner using an XOCP conversation, the 
associated XPATH routers for that trading partner are evaluated against a 
message-context XML document generated by the c-hub for that 
message. The generated message-context XML document contains 
10 information about the sending trading partner, the conversation context, 
the message context, and a sequence of subtrees containing the XML 
parts of the business document. 

C-hub XPATH routers 41 0 - These are routers that are specified by 
15 a c-hub administrator in the repository and associated with all incoming 
messages in an XOCP protocol stack. These routers are similar to the 
trading partner XPATH routers that are sent with a message, but they are 
evaluated after any c-enabler or trading partner XPATH routers. 

A c-hub administrator can specify multiple XPATH routers for the 
20 c-hub and for each trading partner using the c-hub administration console. 
These XPATH routers are stored in the repository. The c-hub 
administrator specifies the XPATH expression for each router, whether 
the router should reference the content in the application message parts, 
and the order in which the XPATH routers should be evaluated for each 
25 trading partner and for the c-hub. 

The message-context XML document that the XPATH expression 
is evaluated against can be generated with or without expanding the child 
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nodes of the <message-part> element. For large application messages 
expanding the <message-part> could have a significant performance 
impact. If an XPATH expression does not reference the content of a 
message-part then the administrator can specify that the router does not 
5 need the message-part to be included. 

Each XPATH router expression in the ordered sequence can be 
configured to replace previous routers (that is, it overrides any routing 
done by a previous router in the sequence), or it can be configured to 
append a subset of trading partners to the previous router results. The 
10 c-hub XPATH routers are evaluated after all of the sending trading partner 
XPATH routers. 

XPATH Filters 

Trading partner XPATH filters 416 - These are filters that are 
15 defined by an administrator and associated with a trading partner. Using 
the c-hub administration console, the administrator defines a filter with an 
XPATH expression and associates it with a trading partner. When the 
c-hub routes a message to a trading partner with the XOCP protocol, the 
XPATH filter is used to examine the message context and determine 
20 whether to send the message to the trading partner or not. The XPATH 
expression is evaluated against a message-context XML document 
generated by the XOCP filter module. It contains information extracted 
from the message context and the repository. If the c-hub evaluation of the 
XPATH expression returns false, then the c-hub does not route the 
25 message to the target trading partner. Otherwise, the c-hub processes 
the message as usual. 

Attorney Docket No.: BEAS-01033US4 SRM/KFK 
kfk/wp/beas/1 033/1 033us4.app.wpd 



-59- 

C-hub XPATH filters 418 - These are filters that are defined by an 
administrator and are associated globally with the c-hub for all XOCP 
messages. Using the c-hub administration console, an administrator 
defines these filters with an XPATH expression. When the c-hub routes a 

5 message to a trading partner in an XOCP protocol c-space, the XPATH 
filter is used to examine the message context and determine whether to 
send the message to the trading partner or not. The XPATH expression is 
evaluated against a message-context XML document generated by the 
XOCP filter module. It contains information extracted from the message 

10 context and the repository. If the c-hub evaluation of the XPATH 

expression returns false, then the c-hub does not route the message to the 
target trading partner. Otherwise, the c-hub processes the message as 
usual. 

An administrator can specify multiple XPATH filters for each 
15 trading partner and for the c-hub. The c-hub administrator uses the c-hub 
administration console to specify the order in which the filters should be 
evaluated for each trading partner and for the c-hub. The filters for the 
c-hub are evaluated after the filters for a target trading partner. Each filter 
has an XPATH expression and an indication as to whether to expand the 
20 <message-part> element of the message-context XML document. 

Each XPATH expression in the configured sequence must evaluate 
to a Boolean true or false result. If the c-hub evaluation of an XPATH 
expression evaluates to false, then the c-hub does not send the message 
to the target trading partner and no further filtering is performed. 
25 Otherwise, the c-hub continues to process the XPATH filters until either a 
subsequent filter in the sequence returns false, or until all filters return true. 
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The message-context XML document generated for a c-hub or 
trading partner XPATH filter is almost identical to the document generated 
for an XPATH router. The only differences are that the context attribute on 
the root element is identified as "hub-filter" or "trading-partner-filter", and 
5 the set of target <trading-partner> nodes is always just a single 
occurrence. 

Bridges, Gateways and Proxies 

Since the invention is designed to be as flexible as possible in 

10 facilitating enterprise-wide e-commerce collaboration, the collaboration 

system may support a number of complex scenarios that extend the reach 
of the collaborative workflow beyond that described earlier. These 
scenarios include the use of bridges, gateways, and proxies. 

Figure 22 shows an example of a bridge (c-bridge). The c-bridge 

15 424 is used to connect two separate c-spaces 426, 428, and to provide 

workflow communication between them. Any trading partner may act as a 
c-bridge, which may be configured to subscribe to messages from one c- 
space, transform them to the vocabulary of a second c-space, and then 
publish the transformed message into the second c-space. This capability 

20 provides a simple way of combining business models on the Web. 

Figure 23 illustrates a c-gateway. The c-gateway 430 can be used 
to publish messages from a c-space 432 to external system 434, such as 
Ariba Net. Other c-gateways can be used for other systems, including any 
that use XML as a message receiving and sending protocol. 

25 Figure 24 illustrates a c-proxy. C-proxies 438 may be used to 

send and receive messages from a c-space 440 to a remote client 442, 
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such as an email system, XSL display device, or a wireless (WAP) 
device. 

RosettaNet Protocol Router 

5 A RosettaNet router, using the business protocol plug-in 

mechanism, allows RosettaNet messages to be routed by the 
Collaboration Server hub between any two participating RosettaNet 
clients. The clients supported include "native RosettaNet" clients like 
Vitoria and webMethods. 

10 An example of a RosettaNet router is shown in Figure 21 . The 

"RosettaNet router" should not be confused with the previous use of 
"router". By itself, "router" refers to a Logic Plug-In in a particular chain in 
the c-hub. "RosettaNet router" refers to the entire RosettaNet protocol set 
of Logic Plug-Ins, solely oriented toward sending messages from one 

15 RosettaNet client to another ("routing"). 

The RosettaNet router supports the Vitoria and webMethods 
implementations of external RosettaNet clients. In order to perform proper 
routing, the RosettaNet router needs information from the Preamble and 
Service Header XML components of the RosettaNet object in order to 

20 conform to the RosettaNet specifications. This is explained later in the 
Message Processing section. The out-of-the-box RosettaNet router is 
intended to comply with the published RosettaNet standard (as detailed in 
the RosettaNet specification at www.rosettanet.org, herein incorporated 
by reference) and is not biased towards any one vendor. 

25 When an RNO (RosettaNet message) is received by The 

Collaboration Server and sent to the decoder portion 404 of the business 
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protocol for processing the message the following happens: 
The RNO format is not changed: 

The digital signature is not validated. Validation of the digital 
signature is expected to be done by the receiving trading partner. 
5 Read-only access is required to the document in order to retrieve 

the information needed for routing purposes. The generic c-hub 
RosettaNet router does not modify the document. However, 
customer-provided Logic Plug-Ins or business protocol plug-ins might do 
so. 

10 All of the XML components are processed: the Preamble, the 

Service Header, and the Service Content. 

Because of the above processing, the following information must 
be valid for the routing to proceed: 
15 RosettaNet Implementation Framework (RNIF) version 

RNO content length 

MIME multipart structure, including: 

Content-Type 

Boundaries 
20 Valid XML for the Preamble 

Valid XML for the Service Header 

Well-formed XML for the Service Content 

25 RosettaNet Object Routing and Conversation Information 

Routing and conversation information is constructed from parsing 
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the RNO's XML parts. The c-space is determined based on the URL used 
to access the c-hub. The remaining RNO fields must be valid in form and 
in how they are used: 

5 //Preamble/Versionldentif ier : The RNIF version number. The 

only RNIF version that The Collaboration Server will support is "1.1". 

//ServiceHeader/ProcessControl/ProcessIdentity/GlobalProcess 
IndicatorCode : The PIP identifier. 

10 This typically has a value like "3A4" and it is used as the 

conversation name. It must be entered as such in the repository. 

/ /ServiceHeader/ProcessControl/ProcessIdentity/Versionldentif ie 

r : The version of the PIP specification used. This typically has a value like 
15 "1.1" and should not to be confused with the RNIF version number. It is 
used as the version number of this conversation. It must be entered as 
such in the repository. 

//ServiceHeader/ProcessControl/TransactionControl/PartnerRoleRo 
20 ute/f romRole/PartnerRoleDescription/GlobalPartnerRoleClassif ica 

tioncode: The "from role" or the role of the sender. This typically has a 
value like "Buyer" and it is used as the role of the sender in the 
conversation. It must be entered as such in the repository. 

25 //ServiceHeader /ProcessControl /Transact ionControl/ Par tnerRoleRo 

ute /toRole/PartnerRoleDescript ion/Global PartnerRoleClas si ficati 

oncode: The "to role" or the role of the recipient. This typically has a value 
like "Seller" and it is used as the role of the recipient in the conversation. It 
must be entered as such in the repository. 

30 
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//ServiceHeader/ProcessControl/TransactionControl/ [ActionContro 
1 | SignalControl ] /PartnerRoute/f romPartner/PartnerDescription/Bu 
sinessDescription/GlobalBusinessIdentifier: The business identifier 

of the sender of this message. For the unique business identifier, 
5 RosettaNet specifies use of the 9-digit DUNS number. It must be entered 
as such in the repository. The business identifier is used to identify the 
sending trading partner in the conversation. 

/ /ServiceHeader/ ProcessControl/ Trans act ionControl/ [ActionContro 
10 1 j SignalControl ] /PartnerRoute/toPartner/PartnerDescription/Busi 

nessDescription/GlobalBusinessIdent ifier: The business identifier of 
the recipient of this message. It is similar to the "fromPartner" business 
identifier. The business identifier identifies the recipient trading partner in 
the conversation. 

15 

// ServiceHeader /ProcessControl/ProcessIdentity/ 

mstanceidentifier: A supposedly unique alphanumeric identifier for 
this business process, though RosettaNet also states that the initiating 
partner's business identifier (DUNS number) should be used. These two 
20 numbers are combined to form the conversation id, but are only used for 
monitoring and auditing purposes, not for routing purposes. 

/ /ServiceHeader /ProcessControl /ProcessIdentity/initiatingPartne 
r/GlobalBusinessIdent ifier: The initiating partner's business identifier 
25 (DUNS number). As stated earlier, this is used to construct the 
conversation id. 

//ServiceContent/thisDocumentldentif ier /ProprietaryDocumentlden 

tifier: The document identifier. This is the initiator. 
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//ServiceContent/thisMessageldentif ier/ProprietaryMessageldenti 

fier: This document identifier. This is a follow-on document in the 
same dialog. 

5 / /ServiceContent/receivedDocumentldentif ier/ProprietaryDocument 

identifier: The initiating document identifier. 

When decoding the RosettaNet message, an additional check can 
be made that the DUNS identifier of the sender, as retrieved from the 

10 message, matches that of the certificate. Since the c-hub is acting as a 
trusted intermediary, this will validate that the sender is who is claimed 
before the message is passed on to the recipient. If the match fails, the 
message will be rejected by the c-hub. 

The collaboration server processing layers and business protocols 

15 neither generate nor validate any digital signature associated with the 
message because this is an issue among the various trading partner 
clients, whereas the c-hub is simply relaying messages. The c-hub only 
validates based on the SSL certificate. 

If a particular business protocol is passing messages that have a 

20 digital signature, then the operations that a Logic Plug-In can perform on 
those message will generally be restricted to read-only unless the Logic 
Plug-In is allowed to re-sign messages on behalf of the original sender (or 
has access to the original sender's certificate / private key). However, 
nothing prevents a hub-provider from introducing Logic Plug-Ins that can 

25 validate or generate digital signatures. 
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Replying to the RosettaNet Sender 

RosettaNet is a point-to-point protocol, and not prepared to interact 
with an intermediate hub. There are two main ways to approach the hub 
issue with RosettaNet - Synchronous and Asynchronous Message 
5 Transfer. 

Synchronous Message Transfer 

In this approach, the sender delivers a message to the c-hub, and 
the message passes all the way through the c-hub to the recipient, who 
10 returns the HTTP status code. The transport layer then returns that status 
to the layer initiating the outbound request, which passes it back through 
the various c-hub layers and eventually to the sender. 

Asynchronous Message Transfer 

15 This approach can also be referred to as a "delegated 

responsibility" model. The c-hub already needs to do about the same 
level of initial validation that the recipient would need to do. Enough of the 
lengths and first two XML components need to be checked that the 
message should make it to the upper protocol-processing layer of the 

20 recipient. In this case, it should be acceptable for the c-hub to send back 
the OK / BAD response after its initial processing. All responses may be 
logged. 

An advantage to this approach is that the message persistence 
capabilities of the c-hub allow delivery to a recipient that is temporarily 
25 unavailable. Many of the problems that may be encountered by the 

RosettaNet recipient would already have been caught and reported by the 
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c-hub. If the RosettaNet client starts processing the message and 
encounters errors at the business rule level (message content), a separate 
out-of-band error reporting mechanism is already provided by RosettaNet, 
and this can be routed through the c-hub like any other RosettaNet 
5 message. 

If the c-hub thinks a message is not valid that the recipient might 
accept, then the hub-provider will have to determine which party is 
non-compliant, the sender, the c-hub, or the recipient, and take 
appropriate 

10 action. For example, if it was the c-hub, the RosettaNet router could be 
modified for different behavior (presumably being less strict in compliance 
checking). 

If the recipient rejects a message that the c-hub accepted, again 
the hub-provider will probably have to get involved to determine the 
15 non-compliant party. However, the recipient would generally respond to 
the c-hub with a BAD REQUEST message, which the c-hub can log and 
pass back a RosetttaNet" General Exception" RosettaNet PIP to the 
initiator with the information. 

20 XML Processing 

The RosettaNet router needs important pieces of information from 
the Preamble and Service Header. This will be parsed with a validating 
XML parser. An error here will be logged and returned to the sender as a 
rejected message. 

25 To properly function, the RosettaNet router does not need to fully 

parse and validate the Service Content portion. The Service Content is 
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the business-specific portion of the message and is more appropriately 
handled by the receiving client. The information obtained here is for 
monitoring purposes. Furthermore, to validate the Service Content would 
require storing over 100 additional RosettaNet PIP DTDs, not including 
5 variations that might enter due to trading partner specific customization. 
The Service Content will be parsed as a "well-formed" document in order 
to retrieve the few non-essential fields required. If this part is not 
well-formed, however, the message will be logged and rejected by the 
c-hub. 

10 For all of the XML parts, specifying an "XPath" expression for the 

field can retrieve the value for that field. For the Service Content part, the 
root node should be specified as "ServiceContent", as shown earlier. It 
will be replace by the appropriate message-specific root node when 
evaluating the XPath expression. 

15 The Logic Plug-In mechanism does not preclude the customer from 

doing their own XML parsing and processing of the Service Content, 
however. This would allow for filtering or monitoring based on the content 
of the Service Content portion of the message. The customer will be 
responsible for the parsing, however, in order to do the filtering. 

20 

The RosettaNet router requires certain fields to be entered in the 
repository, typically via the administration console. The required 
additional information includes: 

DTD to be able to parse the RosettaNet Preamble 
25 DTD to be able to parse the RosettaNet Service Header 

DUNS for the trading partners participating in RosettaNet 
conversations. The "Trading Partner Protocol" repository item mentioned 
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earlier is where this information is stored, and can be entered via the 
administration console. 

Appropriate conversation and subscription information for the 
trading partners. The conversation information must match the 
5 conversation information specified in the RNOs being exchanged, as 
described earlier. 

UML Configuring of C-spaces 

Extensible Markup Language (XML) is rapidly becoming a key 

10 enablerfor EAI and B2B e-commerce. In most EAI and B2B scenarios, 
the greatest challenge is creating a dynamic free flow of information and 
knowledge between applications and enterprises. XML provides an open 
and flexible message format, or common dialect, for structuring 
information flow between heterogeneous systems. 

15 XML is a metadata language, a language used to define other 

languages and a universal standard for structuring data. XML is 
intrinsically extensible and self-describing, and thus supports an extremely 
flexible and dynamic business environment. XML easily enables the 
transfer of information across the Internet and between organizations, 

20 allowing them to communicate and conduct Dynamic B2B. Dynamic B2B 
requires technical underpinnings that adapt to changing e-business 
strategies and can be extended across multiple enterprises, business 
partners, and diverse applications. 

In one embodiment of the invention, using Rational Rose, a c- 

25 space can be constructed using the unified modeling language (UML). 

Figure 25 illustrates the steps required in generating the XML model for 
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use with the c-space. Activity diagrams, state charts, and class diagrams 
are used to define transaction models between roles, workflow state 
models, and a message space, respectively 450. The UML models are 
then used 452 to generate XML and to populate repositories with this 

5 information 454. The repositories are read at run-time by the various 
components of the present system to determine correct behavior 456. 
Since a configuration information is represented (and stored) in XML, it is 
possible to use off-the-shelf revision/configuration management tools to 
manage changes to the c-space configurations. 

10 The Message Type System is a polymorphic hierarchy of message 

types. A message type is an abstraction of information that will be shared 
by transactors (e.g. ORDER, CUSTOMER, PRODUCT etc.). All message 
types share some common behavior, such as how the encapsulated 
information (XML) can be manipulated. Therefore the type system 

15 implements basic manipulation capabilities (create, read, update, delete) 
on the base level. Communication Adapter is a notion that abstracts a 
wire-protocol, such as HTTP, SOAP etc. When a transactor wants to 
communicate with somebody over a network connection, it needs to 
instantiate an appropriate adapter object and then pass it's reference to 

20 the message object. The content of the message object then becomes a 
payload of the network message and the adapter takes care of the 
communication protocol (headers, exceptions, timeouts etc.). 

Message factories can be used to create message objects out of 
incoming network messages. Factories are specific to wire-protocols, not 

25 to message types. So, for example HTTPRequestFactory can handle any 
message that comes over HTTP. If a new message type is added, the 
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existing factory can be leveraged. If support is added for a new wire- 
protocol, a corresponding factory would be implemented as well. 

This embodiment implements a simple workflow engine, which is 
based on the idea of DFA (deterministic finite automata). The engine is 
5 driven by a XML-based flow-language. The schema (DTD) of the 
language looks that of Listing 2. 

<! ELEMENT workflow (state+ )> 
< ! ATTLIST workflow type CDATA # REQUIRED > 
<! ELEMENT state <transition+ )> 
10 <! ATTLIST state time_out CDATA #IMPLIED 

state_id CDATA #REQUIRED> 
<! ELEMENT transition (action )> 

<! ATTLIST transition rule_id CDATA #IMPLIED 



message_id 


CDATA 


#IMPLIED 


state_id 


CDATA 


#REQUIRED 


transitioned 


CDATA 


#REQUIRED 


me s s age_type 


CDATA 


#IMPLIED 


timeout 


CDATA 


#IMPLIED ; 



<! ELEMENT action EMPTY> 
20 <! ATTLIST action rule_id CDATA #IMPLIED 

action_id CDATA #REQUIRED > 

Listing 2 

25 The workflow model is de-centralized, so each transactor executes 

it's own instance of the engine. The implementation manages multiple 
contexts simultaneously, so a transactor can be involved in many (but 
separate) business transactions at the same time. XML is also used for 
storing the state of a workflow context. This allows this embodiment to re- 

30 load the state of a context in a different system. This design has some 
interesting consequences, for example the system should scale nicely in 
the WLS cluster environment. 
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The design process is started by modeling business transaction 
using Use Case diagram. For the example illustrated in Figure 26 the 
following roles were identified: customer, dealer, and shipping company. 
The business transaction is "buy-a-car". 
5 The first step is to break the Use Case into actions, and add those 

to an activity diagram. 

The next step is to take the roles from a use case diagram, map 
those roles to swim lanes of an activity diagram and assign the activities 
to corresponding swim lanes. 
10 The next step is to define messages that will be delivered and 

processed by activities. 

Configuration files (publish/subscribe), message types etc., can 
then be generated from those diagrams. It is also possible to model each 
transactor's DFA by using state chart diagrams and to generate the 
15 necessary workflow definitions out of those: 

Actions 

• Request for Information 

• Send Information 
20 • Place Order 

• Process Order 

• Check Inventory 

• Confirm 



Attorney Docket No.: BEAS-01033US4 SRM/KFK 
kfk/wp/beas/1 033/1033us4.app.wpd 



-73- 



Message Types 

• InformationRequest 

• Information 

• Order 

5 • InventoryCheck 

• InventoryStatus 

• Confirmation 

Flows 

10 • "Customer" 

• "Dealer" 

• "Shipping Company" 

Figure 26 illustrates an example of a workflow model as prepared 
15 using UML, and then generated in XML. The example shown in Figure 26 
describes a workflow between a customer 501 , a dealer (or supplier of 
goods) 503, and a shipping company 504. As presented the workflow 
resembles a series of "swim lanes", or process flow lanes, with each entity 
or trading partner having their own "lane". A separate lane is reserved for 
20 the publish/subscribe entity 502 which, under control of the conversation 
manager, is responsible for receiving and sending messages between the 
various other entities. 

Referring now to Figure 26, it can be seen that the customer 
begins the workflow by requesting a catalog 462. The catalog request is 
25 sent as a message 464 to the publish/subscribe service. This messaging 
process, and all other messaging processes indicated in Figure 26 are 
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controlled or coordinated by the conversation manager which is 
responsible for the flow of messages throughout publish/subscribe "swim 
lane". The catalog request message is thus sent to the dealer, who 
responds with a send catalog message 466. Having received the catalog 
5 the customer may wish to place an order 470, and a place order message 
is duly issued 472. The workflow indicates this message should be sent 
to the shipping company rather than the dealer, and so the conversation 
manager/c-hub routes it accordingly 474. On receipt of the send order 
message the shipping company may issue a request to check the 

10 inventory 478. If the inventory check indicates the item is in stock 480 then 
a confirmation message 482 can be sent to the customer seeking final 
verification 486. Decision steps may be included in the workflow to allow 
for unusual or unexpected events. In the example shown in Figure 26 a 
decision block 494 is included to allow for the possibility that an item may 

15 not be in stock. If this happens then the workflow may be designed to 

perhaps request additional information before proceeding or jumping to a 
different workflow path. 

Industrial Applicability: 

20 The invention helps to define an open market platform system for 

conducting business-to-business commerce or the Web. The 
collaboration system defined herein includes many novel and industrially 
applicable features, some of which are listed here. 



Attorney Docket No.: BEAS-01033US4 SRM/KFK 
kf k/wp/beas/1 033/1 033us4.app.wpd 



-75- 

Mainframe Connectivity 

There are tens of thousands of IBM CICS applications hosted on 
the IBM MVS and VSE operating systems, and deployed on mainframes 
in every country around the world. Hundreds of the world's largest 
5 databases are accessed through IMS on IBM's MVS S/390 platforms. 

Unlike most EAI vendors, the collaboration system provides the greatest, 
most robust connectivity to mainframe applications. The collaboration 
system provides connectivity to the following: TCP, SNA and OSI TP. 

10 Adapter Integration for Major Packaged Applications 

The collaboration system products minimize programming, which 
greatly reduces the development effort required to connect applications. 
The emphasis is instead on configuration, which not only saves 
programming costs, but also enables developers to focus on building new 
15 e-business applications that will significantly improve their company's 
competitive edge. 

Support for XA-Transactions 

The collaboration system provides transparent support for XA- 
20 transactions. Message-based EAI products define a transactional unit of 
work to mean only the guaranteed delivery of a message. However, if a 
unit of work between integrated applications translates into multiple reads 
and writes, or if the integrated applications are heterogeneous, there is a 
strong risk of corrupt or inaccurate data, which can only be avoided by 
25 complex programming. This risk is eliminated if applications support XA- 
transactions and are integrated using the collaboration system because 
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the collaboration system includes a full standards-based transaction 
manager capability. 

E-Transaction 

5 An E-Transaction embodiment of the invention enables businesses 

to jointly and successfully accelerate e-commerce strategies in real time, 
empowering dynamic business-to-business transactions. 

The invention enables the participation by a business in the 
process of conducting e-commerce on the Internet with other business 

10 collaborators. This approach is significantly different from back-end 

business transaction systems. First, the "transactions" are of a business 
nature and are long running. Indeed, a business transaction may require 
weeks, months, or even years to complete. The state for such 
transactions must be kept persistently so as not to lose it during various 

15 system failure modes. Thus, a single business transaction can cause one 
or many back-end database transactions to occur. Traditional business- 
to-business e-commerce required businesses to agree on a business 
model for the relationship, a uniform vocabulary, and a messaging 
technology. With the present invention, that is no longer necessary — the 

20 platform is independent of any one business model or vocabulary and 
uses XML as the standard. 

Zero-Latency And End-to-End Integration 

The present invention provides an enterprise-class solution in the 
25 market that provides zero-latency, end-to-end integration. From the 
mainframe to the Web, the collaboration system provides a proven, 
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scalable, and p re-integrated server-based environment for integrating an 
enterprise's packaged and proprietary enterprise applications, whether 
they reside on the back-office, front office, or on the Web. The 
collaboration system performance excels in the most demanding, 
distributed 24x7 environments, and offers a choice of messaging 
paradigms and pre-packaged application adapters and custom Adapter 
Development Kit to best solve the business problem at hand. The 
collaboration system platform migration to XML-based messaging keeps 
the integration solutions at the forefront of technology. 

Other features, aspects and objects of the invention can be 
obtained from a review of the figures and the claims. It is to be 
understood that other embodiments of the invention can be developed and 
fall within the spirit and scope of the invention and claims. 

The foregoing description of preferred embodiments of the present 
invention has been provided for the purposes of illustration and 
description. It is not intended to be exhaustive or to limit the invention to 
the precise forms disclosed. Obviously, many modifications and 
variations will be apparent to the practitioner skilled in the art. The 
embodiments were chosen and described in order to best explain the 
principles of the invention and its practical application, thereby enabling 
others skilled in the art to understand the invention for various 
embodiments and with various modifications that are suited to the 
particular use contemplated. It is intended that the scope of the invention 
be defined by the following claims and their equivalence. 
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